home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950726-19950929
/
000099_news@columbia.edu_Mon Aug 7 12:52:35 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-12-25
|
2KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17322
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 7 Aug 1995 08:52:43 -0400
Received: by apakabar.cc.columbia.edu id AA07566
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 7 Aug 1995 08:52:41 -0400
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Packet length and file transfers
Date: 7 Aug 1995 12:52:35 GMT
Organization: Columbia University
Lines: 33
Distribution: USA
Message-Id: <4052aj$7cc@apakabar.cc.columbia.edu>
References: <3vrtpa$p0r@gold.tc.umn.edu>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3vrtpa$p0r@gold.tc.umn.edu>,
Jim Scott <scott048@gold.tc.umn.edu> wrote:
: I've finally managed to get kermit to transfer files reliably and have
: moved on to the next stage -- improving transfer performance. I download
: lots of .zip files and have played with buffer sizes, packet lengths and
: window slots.
:
: I've got my window slots set to 31, CTS flow control, 57600 speed with a
: 14.4 modem using compression and error correction. My control prefixing
: is limited to three characters.
:
: I average about 1,550 file characters/second when I use packet lengths
: beteween 200-300 characters. When I increase that to 1000+, my transfer
: rates fall to 1,200 characters/second or worse. Should I be happy with
: my 1.5, or is there a way to improve this even more using longer-packets?
:
When transferring precompressed files, you might be able to squeeze out
a few more percent by turning off Kermit's compression ("set repeat counts
off"). Turning off the modem's compression is usually not worth it.
Then you can experiment to find the optimal combination of window size and
packet length. Every connection has its own, and the curves are not
necessarily predictable.
However, for transferring ZIP files on a V.32bis/V.42/V.42bis connection,
you aren't going to get much better than 1600 cps no matter what you do,
so you'll have to decide if the experimentation is worth it -- the gain
would be about 4 percent.
Also be aware of other limiting factors, such as terminal server capacity,
buffer size, and speed.
- Frank